ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group95c.txt/000110_icon-group-sender _Mon Dec 4 14:17:05 1995.msg

Internet Message Format | 1996-01-03 | 2KB

Received: by cheltenham.cs.arizona.edu; Mon, 4 Dec 1995 16:34:33 MST
Date: Mon, 4 Dec 1995 14:17:05 -0800
From: [e-mail] (Ken Walker)
Message-Id: <[e-mail].>
To: [e-mail], [e-mail]
Subject: Re: Generators and/vs. coroutines ?
X-Sun-Charset: US-ASCII
Errors-To: [e-mail]

> Date: 4 Dec 1995 17:01:09 GMT
> From: John Lindsay <[e-mail]>
>
>...
>
> Is an Icon generator anything more or less than a coroutine which can
> be instantiated by an explicit call with value arguments, and can
> 'return' a function value across the coroutine boundary ?

A generator is less than a coroutine (but, as they say, "less is more" ;-). This can
been seen in the way the two are implemented. A coroutine is given its own call stack,
but a generator isn't. A generator is a function that stays on the call stack as
long is it might be resumed to produce another value. This works well because a generator
is never resumed until everything called after it has terminated and been removed
from the stack; backtracking is last-in first-out. When a generator is resumed, the
call stack has returned to the state it was in when the generator suspended. Note,
if you are trying to use the call stack as an expression evaluation stack (as is sometimes
done in interpreters), the long-lived stack frames get in the way, but that can be
dealt with by employing some extra copying of intermediate values around the suspended
stack frames to the top of the stack.

Ken Walker, [e-mail]
Premenos Coporation, Concord, Ca. 94520